Analysis of PCI DSS v4.0 – Part IV: Requirements 5 and 6

In this fourth instalment of the series “Analysis of PCI DSS 4.0” a review of the changes in requirements 5 and 6 of the PCI DSS standard between versions 3.2.1 and 4.0 is presented. These two requirements are focused on protection at the software level to prevent, detect and mitigate the exploitation of vulnerabilities in the system components within range.

In PCI DSS version 4.0, these requirements were renamed to clarify and expand their scope, addressing some of the restrictions identified in version 3.2.1.

Requirement 5: Protect All Systems and Networks from Malicious Software

Since its first version, the PCI DSS standard has included controls for detection, removal, blocking and containment against malicious code (malware). However, until version 3.2.1, these controls were generically referred to as “antivirus software” (Anti-virus Software), which was incorrect from a strictly technical point of view, since this type of solution not only protects against viruses (as the name implies) but also against other known variants of malicious software (worms (worms), Trojans (trojan horses), ransomware, spyware, rootkits, adware, backdoors, etc.).

For this reason, from version 4.0 of PCI DSS the term “antimalware” to cover not only viruses but also all other families of malicious code, which is more consistent with the objective of this requirement.

Difference between "antivirus" and "antimalware"

Other changes incorporated in this new version of the standard were:

• To avoid the ambiguities seen in previous versions of the standard about which operating systems should have an anti-malware solution installed and which should not, a more operational approach has been chosen: the institution should conduct a periodic assessment to determine which system components should require an anti-malware solution. All other assets determined not to be affected by malware must be listed (req. 5.2.3).
• Updates to the antimalware solution must be made automatically (req. 5.3.1)
• Finally, the term “real-time scanning” for the anti-malware solution (this is a type of persistent and continuous scanning where security risk analysis is performed every time a file is received, opened, downloaded, copied or modified). Previously, reference was made to the fact that anti-malware mechanisms should be actively implemented (intense running), which gave rise to different interpretations.
• Incorporated continuous analysis of the behaviour of systems or processes as a method of scanning the accepted anti-malware solution, as an alternative to traditional periodic scans (programmed and on-demand) and real-time scans (real-time u on-access) – Req. 5.3.2.
• As for scheduled scans, their periodicity must be configured based on a risk analysis (req. 5.3.2.1).
• It incorporates the obligation of the scanning of removable storage media (Req. 5.3.3).
• The retention of the logs of the antimalware solution is aligned to the general criteria of log management (12 months with availability of the last 3 months for immediate analysis - req. 5.3.4).
• It incorporates the mandatory use of mechanisms to detect and protect against phishing attacks (Req. 5.4.1). In this case, the controls to be implemented go beyond the installation of an antimalware agent, involving configurations at the level of email servers (without these servers having to be in range).

Requirement 6: Develop and Maintain Secure Systems and Software

Like the vast majority of PCI DSS requirements, requirement 6 was also no stranger to the change in its name, which this time expands its scope to cover not only applications but software in general. In this line, it is clarified that controls of this requirement apply to all system components, with the exception of section 6.2 which applies only to customised or internally developed software.

The most relevant changes to controls for custom or in-house developed software are:

• The order of the controls in the requirement was changed, organizing in section 6.2 the controls for customized or internally developed software, section 6.3 for the management of updates and vulnerabilities, section 6.4 for the protection of web applications with public access and section 6.5 for change management.
• Priority was given to the application of security controls in customized or internally developed software to prevent vulnerabilities throughout the phases of the development life cycle.
• Details on the content of the training for developers (Req. 6.2.2):
  • Must be performed annually
  • Must cover the programming languages used
  • You must incorporate information about the tools used to detect vulnerabilities
• As for the code review, should be carried out in accordance with secure development guidelines, include reviews of existing and emerging vulnerabilities and apply corrections before they are put into production (req. 6.3.2).
• Some of the “traditional” vulnerabilities in software development (SQLi, XSS, CSRF, etc.) were grouped into a single requirement (req. 6.2.4).

On the other hand, for the management of security vulnerabilities, the following controls were added/complemented:

• In PCI DSS version 4.0, req. 6.3.3 (former 6.2), "High" and "critical" patches must be installed within the first month after publication. In PCI DSS v3.2.1 only the installation of "critical" patches was required.
• Vulnerability identification should cover not only “base” software (operating systems, databases, applications, network equipment) but also libraries, compilers, programming languages
• The concept of “bug bounty” as an additional tool for third parties to report vulnerabilities to the institution (req. 6.3.1).
• It requires the creation of a inventory of custom or in-house developed software, including linked components such as libraries, services, frameworks, etc. (req. 6.3.2, which will enter into force on 31 March 2025).
• As of 31 March 2025, the use of an automated technical tool to detect and prevent web attacks in real time (such as a Web Application Firewall – WAF, for example). The periodic execution of tools for scanning web applications, which was offered as an option for the protection of web applications with public access, will no longer be valid.
• Control 6.4.1 (protection of publicly accessible web applications) mentions the technology of Runtime Application Self-Protection (RASP) as a complementary tool to Web Application Firewall (WAF).
• Finally, many of the criteria that had been presented in the document were incorporated into the standard. Information Supplement: Best Practices for Securing E-commerce, including the implementation of technical methods for the protection of scripts on payment pages loaded and executed in the user's browser, including:
  • Controls to confirm that each script is authorized
  • Controls to verify the integrity of each script
  • An inventory of all scripts used with their related justification.

This check will be valid from March 31, 2025.

On the other hand, in terms of change management:

• The use of real PAN numbers (live PANs) in pre-production environments if these environments are included in the CDE and protected in accordance with PCI DSS.
• Change management includes changes made to custom or in-house developed software.

In the following article of this series, the requirements 7, 8 and 9 of PCI DSS will be analyzed, focused on the management of physical and logical access control to the environment.

References

• Information Supplement – Best Practices for Securing E-commerce https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf
• Defending Against Phishing & Social Engineering Attacks – A Resource Guide from the PCI Security Standards Council https://www.pcisecuritystandards.org/documents/PCI_SSC_Phishing_Resource_Guide_-v06.pdf